Construye sueños digitales:
los cimientos invisibles
Más que código: escuchar, priorizar y dar forma a lo que las personas necesitan.
Brújula del taller
Analizar necesidades, usuarios y restricciones de una aplicación mediante la identificación de requerimientos funcionales, no funcionales y técnicos, integrando empatía con los stakeholders y criterios de priorización, para construir soluciones tecnológicas éticas, viables y centradas en el ser humano.
El origen: tu barrio, tus ideas
¿Has visto algún negocio de tu barrio que aún apunta pedidos en una libreta? Imagina que puedes crear una app para Doña María, la de la tienda de la esquina. Ella te cuenta: “necesito que los clientes me encarguen por WhatsApp, pero sin perderme, y saber si hay stock”. Justo ahí empieza todo. Antes de escribir una sola línea de código, debes entender su mundo, sus miedos a la tecnología y lo que para ella es “fácil”. Bienvenido al análisis de requerimientos: el puente entre una necesidad humana y una solución digital. Vas a ser detective, arquitecto y psicólogo a la vez.
Los planos de tu app
Vamos por partes. Cada tipo de requerimiento es un lente para ver el proyecto completo.
Requerimientos funcionales
Lo que el sistema HARÁ. Son acciones, comportamientos, procesos. Ejemplo: “La app debe enviar un mensaje de confirmación al recibir un pedido”. Si no lo hace, la función no existe. En el caso de la tienda: “registrar producto, mostrar catálogo, actualizar stock”.
Requerimientos no funcionales
Cómo debe ser la experiencia. Atributos de calidad: rapidez (rendimiento), seguridad, usabilidad. “Doña María necesita que cargue en 2 segundos aunque el internet esté lento”. No son funciones visibles, pero definen el placer de uso.
Requisitos técnicos
Restricciones de construcción. Plataforma (Android/iOS/web), lenguaje, base de datos. Ejemplo: “desarrollar con flutter para usar mismo código en iOS y Android” o “requiere cámara con enfoque manual”.
Usuarios & stakeholders
Quiénes viven la app. Usuarios finales (Doña María, clientes) y stakeholders (dueño, proveedores, repartidor). Cada uno tiene necesidades distintas. Si el repartidor necesita geolocalización y no lo consideras, el sistema falla.
Priorización de requerimientos · MoSCoW
Must have (obligatorio), Should have (debería), Could have (podría), Won't have (no ahora). Con Doña María, lo vital es recibir pedidos y notificar. “Podría tener” un historial de ventas, pero no es esencial en la versión 1. Priorizar evita proyectos infinitos.
Escenario real: Para la app de la tienda de barrio, enumera:
✅ Funcional: “registrar pedido con nombre del cliente, productos y total”.
⚙️ No funcional: “debe poder usarse sin conexión y sincronizar después”.
🧩 Técnico: “usar Firebase para datos en tiempo real”.
🧑🤝🧑 Stakeholders: dueña (quiere simplicidad), clientes (quieren fotos de productos), proveedor (quiere reporte de ventas). Prioridad MUST: flujo de pedido y foto de productos (should have).
El reto final: «Raíces digitales»
En equipos de 3, imaginen que una cooperativa de artesanos de Otavalo les pide una plataforma para vender sus tejidos a todo el país. Elabora un documento de análisis que incluya:
- 5 requerimientos funcionales (acciones concretas).
- 4 no funcionales (rendimiento, accesibilidad, idioma, privacidad).
- Requisitos técnicos (dispositivos, stack sugerido).
- Lista de stakeholders (artesanos, clientes, transportistas, etc).
- Priorización con método MoSCoW y justificación breve.
Presenten su análisis al resto de la clase como si fueran consultores senior. Lo importante no es la tecnología, sino la comprensión del entorno humano.
Game over? No, ¡aprueba con estilo!
Demuestra lo que asimilaste. 5 preguntas, puntaje máximo 500.